This invention relates to distributed object systems using Common Object Request Broker Architecture (CORBA) and, more particularly, to a method and apparatus for implementing group object identification in object adapters.
Software programs are continually becoming more complicated. Early programs consisted of straightforward procedural code that presented a simple, command line interface and text display to the user. These simple programs have gradually been replaced with complex programs that have graphical user interfaces and multiple features.
As programs have grown in complexity, the amount of effort which is required to write and debug the programs has also increased drastically. Consequently, major efforts have been made to reduce the amount of programming necessary to produce a modern, full-featured product. One of the most successful of these efforts has been the development of object-oriented programming in which programs are designed as collections of discrete elements called xe2x80x9cobjectsxe2x80x9d. The objects can be modified and re-used in many cases, thereby reducing the development effort.
As will be understood by those skilled in the art, objects in the context of object-oriented programming are software entities comprising data and methods or operations on that data. The methods of an object collectively form an interface for manipulating the data in the object. The objects exist only at program runtime and are created, or instantiated, from object xe2x80x9cclassesxe2x80x9d which are actually written by the programmer. The class code written by a programmer can be xe2x80x9creusedxe2x80x9d by another programmer by instantiating objects from that code.
In order to further reduce the programming burden, distributed object systems have been developed in which methods in objects resident on a server can be executed or invoked remotely over a network from a client application. In this manner, the objects can be developed and maintained by a party different from the party that developed the client application. In such a system information is routed or streamed between the client and the server. This information includes requests from the client to invoke an object on the server and results and data from the method invocation returning from the server to the client. In addition, object-oriented programs often communicate by streaming objects from one program to another.
In such streaming operations, a stream writer organizes, or marshals, the information to form a serial data stream. The serial data stream is then sent to the server where a stream reader unmarshals, the serial data stream to reconstruct a copy of the original information. The stream reader must operate such that the unmarshaling exactly xe2x80x9cundoesxe2x80x9d the effect of the marshaling so that the original information can be reconstructed. Ordinarily, such an operation does not present a problem, but when the stream reader is not written by the same author as the stream writer there can be incompatibilities.
In order to standardize the marshaling and unmarshaling and data transfer process, an industry consortium called the Object Management Group (OMG) was formed whose mission is to define a set of interfaces for inter-operable software. Its first specification, the Common Object Request Broker Architecture (CORBA) specification, is an industry consensus standard that hides all differences between programming languages, operating systems, and object location. The CORBA standard defines an object request broker (ORB) that handles the marshaling, transport and unmarshaling of information between applications. The ORB functions as a communication infrastructure, transparently relaying object requests across distributed heterogeneous computing environments. Inter-operability is accomplished through well-defined object interface specifications which allow client applications to connect to the ORB. CORBA provides an implementation independent notation for defining interfaces called the OMG Interface Definition Language (IDL).
The OMG CORBA specification defines an implementation independent object model which is actually built with a programming language, such as C++ or Java. In this model CORBA objects (also called xe2x80x9cservantsxe2x80x9d), which are implemented by servers, have references that can be exported to clients. Clients and servers are roles, not mutually exclusive tasks for a single program, so that any one program can be both a client and a server. Objects and object references are typically different programming language objects, although they do not have to be. An object may also be controlled by an object manager.
In a server, the implementation of an actual object which can be used to satisfy an invocation on a CORBA object is generally both platform and language dependent and various models are possible for implementing objects in servers. The original CORBA standard defined a Basic Object Adapter (or BOA) which is a framework that adapts the server implementation to the implementation independent ORB. A newer OMG portability standard defines a Portable Object adapter (or POA), which replaces the BOA and is intended to be platform independent. Many ORBs also support other proprietary frameworks for implementing CORBA objects. All of these frameworks are commonly referred to as Object Adapters (or OAs).
Invocations on servants are conventionally performed by invoking a method on an object reference. As part of this invocation, the manager for the particular object (if there is such a manager) is typically given control of the process at some point before, and typically after, the actual invocation on the servant. There are many reasons for this transfer of control. For example, the object manager may have to create the servant, or the object manager may serialize all accesses to the servant. Alternatively, the servant""s persistent data may need to be updated among other reasons.
When a multi-threaded ORB relinquishes control to the object manager, it is important, and, in most cases mandatory, that the ORB release any resource locks it is holding while performing a particular invocation. The ORB may be holding such locks to ensure that accesses to data shared between multiple threads are controlled in order to avoid non-deterministic behavior. Examples of such shared data are tables, access to transports, repositories, etc.
It is important that the ORB release the locks when the object manager has control for a number of reasons. For example, the object manager may need to use functionality provided by the ORB, and, if the ORB does not release locks it is holding, a deadlock would occur where the object manager cannot use ORB functionality, since the ORB itself is already locked. Another reason is that while the object manager is active, another thread may wish to use the services provided by the ORB, and it can only do so if the locks that the ORB is holding have been released.
It is therefore important that, when the ORB relinquishes control during so-called xe2x80x9cupcallsxe2x80x9dxe2x80x94either to object managers, to servants, or to other entities, it releases the locks it is holding while the upcall is taking place. However, it is also important that, as soon as the upcalls terminatexe2x80x94whether by normal termination, or due to an exception, that the locks that were temporarily released are re-acquired. If the locks are not re-acquired, then the locking invariants for the ORB implementation are broken, potentially causing deadlocks which will stop the process from executing.
Therefore, it would be desirable to have a simple mechanism for enforcing the locking invariants during upcalls.
In accordance with the principles of the invention, a special inverse lock class is defined whose constructor stores a reference to, and then releases, a previously-acquired lock whose reference is passed into it. The destructor of the class re-acquires the referenced lock. During operation, the class is instantiated, passing in the desired lock before an upcall is made. Instantiation executes the constructor and causes the lock to be released. When the upcall terminates, either normally or by an exception, the inverse lock object destructor is executed causing the lock to be re-acquired. Since the inverse lock object destructor will always be called when the object is destroyed, the locking invariant will always be satisfied.